This PR introduces dynamic environments using a sidecar outputs container.

Proposal ref: go-vela/community#988

Outputs Container Image

When not set, the build will proceed just as it does today, making this feature completely opt-in and easy to turn off.

The input for VELA_EXECUTOR_OUTPUTS_IMAGE will be the image used for the sidecar container that is spun up next to the Vela build. At some point, this could expand to be a programmatic/plugin implementation rather than what it is in this PR — a sleeping container plugged into the volume that is polled after the conclusion of each step.

In the docker-compose.yml, I decided to just go with alpine:latest.

Substitution and Injection relocation

		// perform any substitution on dynamic variables
		err = _step.Substitute()
		if err != nil {
			return err
		}

		c.Logger.Debug("injecting non-substituted secrets")
		// inject no-substitution secrets for container
		err = injectSecrets(_step, c.NoSubSecrets)
		if err != nil {
			return err
		}

This block has moved from CreateStep to ExecBuild for the Docker runtime and will now occur after polling the outputs container. This will allow for dynamic environments such as this:

  - name: write to outputs
    image: alpine:latest
    commands:
      - echo "GREETING=hello" >> /vela/outputs/.env
      - echo "SECRET=whisper" >> /vela/outputs/masked.env
      - echo "IMAGE=ubuntu" >> /vela/outputs/.env
  
  - name: read from outputs
    image: ${IMAGE}       # resolves to `ubuntu`
    pull: on_start
    commands:
      - echo $GREETING  # prints hello
      - echo $SECRET      # prints ***

Updates to privileged image checking

To protect against dynamic invocations of privileged images using this new feature, parsing images to determine whether they should run will now be at runtime. The logic has moved from AssembleBuild to ExecStep/ExecService.

Unfortunately this means that builds will run up until that step is set to execute before denying it, which is a slightly worse UX but I think the tradeoff is worth it.